____ _ _ _ _
| _ \ ___ | |_ (_) _ __ ___ __| | (_) __ _
| |_) | / _ \ | __| | | | '_ \ / _ \ / _| | | | / _ |
| _ < | __/ | |_ | | | |_) | | __/ | (_| | | | | (_| |
|_| \_\ \___| \__| |_| | .__/ \___| \__,_| |_| \__,_|
|_|
- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b- `b
ÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻÂŻ
Systems Engineering
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
top
Der Begriff englisch Systems Engineering (SE) âSystemtechnikâ bezeichnet ein ingenieurwissenschaftliches Fachgebiet sowie einen interdisziplinären Ansatz, um technische Systeme zu entwickeln, zu beschreiben oder modellieren, zu simulieren, zu verifizieren und zu testen. SE ist eng mit dem Model-Based Systems Engineering (MBSE) verbunden.
SE dient der Definition, dem Aufbau oder der Struktur, der Nachvollziehbarkeit, der Abbildung der Funktionen und vieles mehr von komplexen Systemen oder Produkten.cite-ref-1[1]cite-ref-2[2] Es findet Anwendung bei Echtzeitsystemen, bei Systemen von Systemen (SoS) sowie bei sicherheitsbezogenen Systemen. SE kann dabei Systeme fĂźr Anwendungen an Land, in der Luft oder auf dem Wasser nachbilden.
SE basiert auf der Annahme, dass ein System mehr ist als die Summe seiner Subsysteme (bzw. Teile) und versucht daher die Gesamtzusammenhänge und Wirkketten zu betrachten. Es bietet ein organisiertes und formelles Vorgehen, um die Herausforderungen und Probleme von Systemen systematischer zu bewältigen.cite-ref-3[3] Im umgekehrten Fall, d. h. ohne SE-Ansatz, besteht nach der Entwicklung und Herstellung eines Geräts, Bauteils, einer Maschine oder einer Anlage zwar die MĂśglichkeit, die einzelnen Elemente zu verstehen. Die MĂśglichkeit, die Interaktion dieser Elemente zu analysieren, ist jedoch stark reduziert. In diesem Zusammenhang wird auch vom sogenannten âemergenten Verhaltenâ des Systems gesprochen.cite-ref-4[4]cite-ref-5[5] Dabei ist Emergenz das Phänomen, dass aus einfachen Interaktionen innerhalb eines Systems komplexes Verhalten entsteht.
SE kommt meist in technischen Branchen zum Einsatz, beispielsweise in der Automobil-, Luft- & Raumfahrt, oder RĂźstungsindustrie (vgl. auch Wehrtechnik).cite-ref-6[6] Weitere, synonyme Bezeichnungen sind das englisch Systems Design, das englisch Systems Design Engineering und auch englisch Systems Modelling.
Contents
⢠Beschreibung
⢠Geschichte
⢠Hintergrund
⢠Risikomanagement
⢠SysML
⢠Arcadia
⢠Zertifizierung
⢠Organisationen
⢠Siehe auch
⢠Literatur
⢠Weblinks
⢠Einzelnachweise
ââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââââ
Beschreibung
Systems Engineering (SE) ist eine digitale Entwicklungsmethodik, die dazu dient, ein System zu entwickeln. âDigitalâ bedeutet in diesem Fall, dass spezielle SE-Software zum Design von SE genutzt wird. Dabei ist SE generell ein Mittel zum Zweck, kein Selbstzweck. Bei diesem Design kann es sich um ein Gesamtsystem oder um Teilsysteme handeln. SE wird beispielsweise fĂźr ein neues Produkt, einen neuen Service oder eine bestehende Applikation angewendet. Dies kann im Rahmen eines Auftrags durch einen Auftraggeber (auch Kunde) oder bei allen anderen Entwicklungstätigkeiten, -projekten oder -programmen erfolgen. Die Systeme oder Produkte kĂśnnen kleine Geräte (vgl. Smartphone) oder auch groĂe Geräte (vgl. Raumsonden in der Raumfahrt) sein. Häufig ist SE eng verzahnt mit eingebetteten Systemen.
In vielen Fällen spielen dabei das Anforderungsmanagement (vgl. auch Lasten- und Pflichtenheft) und weitere Fachgebiete eine begleitende Rolle. Bei den zu entwickelnden Systemen konzentriert sich das SE auf einen hierarchischen bzw. integrierten Aufbau Ăźber mehrere Ebenen. Die folgende Liste beginnt beim Produkt und arbeitet sich linear zu den kleinsten (âatomarenâ) Einheiten vor. Dies ist vergleichbar mit dem V-Modell:
1. Eine systematische und nachvollziehbare Analyse der Aufgabenstellung
2. Es wird versucht die Funktionalitäten und Nichtfunktionalitäten des Systems abzuleiten
3. Es wird eine logische Systemarchitektur aufgebaut
4. Das Gesamtsystem wird in Sub- bzw. Teilsysteme oder Komponenten oder Module zerlegt
5. Diese Subsysteme sind z. B. die Hardware (einschlieĂlich Mechanik) bestehend aus Elektronik/Elektrik (E/E) und Software
6. Die Einzelteile oder Komponenten werden spezifiziert, implementiert und untereinander verbunden
7. Die Einzelteile mit der physischen Systemarchitektur verbunden
8. Es werden Einzelteile oder das Gesamtsystem hinsichtlich der Modellierung untersucht und gegebenenfalls simuliert
9. Es wird eine Verifizierung durch Tests und falls mĂśglich Validierung der Komponenten und Einzelebenen angestrebt
10. Die gesamte Struktur wird kontrolliert (vgl. auch Versionskontrolle) und dokumentiert
11. Die BerĂźcksichtigung anderer, angrenzender Fachdisziplinen (siehe unten)
Bei den o. g. Schritten, Aktivitäten und Ebenen soll stets der Produktlebenszyklus berĂźcksichtigt werden, wobei der Fokus auf dem âLebenszyklus des Systemsâ liegt. Wie angedeutet arbeitet das SE Ăźber mehrere Ebenen, die sich nach der Komplexität des Systems und den Anforderungen des Auftraggebers richten. SE versucht die verschiedenen Teilgebiete (Maschinenbau, Software, Elektrik und Elektronik (E/E)) und Fähigkeiten in einen einheitlichen und strukturierten Prozess zu integrieren. Der das SE begleitende Entwicklungsprozess wird von der Konzeption Ăźber die Produktion oder Fertigung bis hin zum Betrieb und in manchen Fällen bis zum Abbau beziehungsweise zur Wiederverwertung angewandt. Zudem werden fĂźr jeden Prozessschritt eigene Methoden verwendet, die systematisch angewendet werden sollen.
Im erweiterten Sinne berĂźcksichtigt SE neben technischen auch wirtschaftliche, rechtliche oder soziale Aspekte, sofern diese mittels der SE-Methodik erfasst und abgebildet werden kĂśnnen. FĂźr einige Fragen bieten sich jedoch spezielle Methoden und Werkzeuge an, beispielsweise eine Business Process Modeling Language (BPML). Letztere ist zwar kein Teil des SE, eine Organisation oder ein Unternehmen kann jedoch auch als âSystemâ betrachtet werden. Im besten Fall kann SE die Grenzen oder andere Merkmale des Systems aufzeigen, die dann mit dem Prozessmanagement, dem Risikomanagement (vgl. auch Risikobewertung), dem Kostenmanagement, dem Produktionsprozess usw. in Wechselwirkung treten kĂśnnen.
Organisation und Stellenbeschreibung
Systems Engineering (SE) ist in der Regel Teil einer Organisation oder Division. Es kann in einer Matrixorganisation angewendet werden. Die Tätigkeit als SE wird teilweise auch von Ingenieuren oder Experten in angrenzenden Gebieten ausgeßbt. Die entsprechende Rolle wird in der Regel als Systemingenieur bezeichnet. Der Systemingenieur arbeitet meist mit Softwareentwicklern, Hardwareentwicklern, Qualitätsingenieuren usw. zusammen.
Der sogenannte Systemintegrator ßbernimmt dabei eine spezielle Aufgabe bei der Integration des Systems. Der Systemarchitekt ist dabei fßr das Gesamtsystem zuständig. Der Systemtester ßbernimmt dabei eine Aufgabe des Systemtests. Ist Software beteiligt, wird diese von einem sogenannten Softwareintegrator erstellt.
Wird SE auf ein Projekt bzw. Produkt angewendet, so obliegt die Verwaltung des Projekts jedoch dem Projektmanager und die Verwaltung von Programmen dem Programmmanager. Es kann einen Projektleiter fßr das SE-Projekt geben, der sich um die Eigenheiten des SE-Projekts kßmmert. Bei komplexen Systemen und Entwicklungsprojekten sollte ein SE-Team aus mehreren Systemingenieuren und o. g. Rollen gebildet werden. Da das Fachgebiet SE umfangreich ist und viel Erfahrung bedarf, sind Fachleute im Bereich SE auch als Berater (vgl. Dienstleistung und Entwicklungsdienstleister) tätig.
Aktivitäten, Aufgaben und Methoden
Zu den Methoden und Aufgaben des Systems Engineering (SE) kÜnnen gezählt werden:
⢠Definition und Planung der SE-Aufgaben
⢠Fortschrittsbewertung und Berichterstattung an Stakeholder
⢠Design und Entwicklung des Systems oder der Subsysteme
⢠Systemdokumentation (Funktionsbeschreibungen, Zeichnungen und Handbßcher)
⢠Systemintegration (Schnittstellen), um eine perfekte Einbindung in das nächstgrĂśĂere System zu gewährleisten;
⢠Systemverifikation und eingeschränkt auch -validierung, um sicherzustellen, dass die Anforderungen erfßllt wurden;
⢠Nachhaltige Entwicklung, falls an das System diese Anforderung gestellt wird
SE hat weiterhin die Schnittstellen zu den folgenden Fachdisziplinen zu berßcksichtigen: Konfigurationsmanagement, Produktentwicklung, Qualitätsmanagement bzw. Qualitätssicherung, Releasemanagement, Risikomanagement, Variantenmanagement uvm. Je nach Komplexität und Projektphase des zu entwickelnden Systems unterscheiden sich die Aufgabenschwerpunkte und Inhalte.
Normen und Standards
Es gibt eine Vielzahl von SE-Normen, z. B. die ISO/IEC 15288 Systems and Software Engineering.cite-ref-7[7]
Geschichte
Der erste bedeutende Einsatz des âSystems Engineeringâ (SE) fand 1940 in den Bell Telephone Laboratories bei der Entwicklung der Telefonie statt.cite-ref-8[8] Die verschiedenen Teile des Telekommunikationssystems mussten interagieren, was nur durch ein umfangreiches Systemverständnis und genaue Spezifikation der Anforderungen mĂśglich wurde.cite-ref-9[9] In den 1950er Jahren entwickelte der US-amerikanische Informatiker Jay W. Forresters die âSystem Dynamicsâ Methoden zur Untersuchung von Systemen.
Die neue Disziplin wurde nach dem Zweiten Weltkrieg in der US-amerikanischen Raumfahrt u. a. beim Apollo-Programm (1960â1970er Jahre) und bei der Entwicklung des Space Shuttle weiter erprobt und eingesetzt. Dabei wurde der Ansatz und die Methode des SE durch die NASA weiterentwickelt, welche heute noch das NASA Systems Engineering Handbook kostenfrei zur VerfĂźgung stellt, siehe die Literaturangaben.cite-ref-10[10]
SE wurde in der europäischen Raumfahrt (vgl. European Space Agency (ESA)) nach den Fehlschlägen um die Europa-Raketen verstärkt eingesetzt. Zu den Fehlschlägen kam es, da die verschiedenen Raketenstufen ohne gemeinsame Koordination (viz. ohne Systems Engineering) entwickelt wurden und diese somit nicht aufeinander abgestimmt waren. Daher wurde beschlossen bei der Entwicklung der Ariane-Rakete die Nutzung des SE zu intensivieren, was schlieĂlich mit zu dem groĂen Erfolg der Rakete beitrug. Seitdem ist es in der Raumfahrt Standard, Systemingenieure einzusetzen.
Des Weiteren ist SE eine der begleitenden Methodiken bei der Entwicklung sicherheitsrelevanter Systeme, z. B. fĂźr Schienenfahrzeuge, Flugzeuge und Fahrzeuge. Es findet auch bei groĂen Infrastrukturprojekten wie der Endlagerung radioaktiver Abfälle Anwendung.cite-ref-11[11] Auch die betriebs- wie volkswirtschaftliche Relevanz fĂźr die Kreislaufwirtschaft zur Bewältigung der hohen Komplexität von Produktentwicklung, Liefer- und Recyclingketten wird vermehrt diskutiert.cite-ref-12[12]cite-ref-13[13]
Hintergrund
Spätestens seit Beginn des Informationszeitalters und der digitalen Revolution â also der VerfĂźgbarkeit von Elektronik und spezieller Mikroelektronik (Rechnertechnik, Speichertechnik, Mikrocontroller, Sensortechnik uvm.) â werden Neuentwicklungen technischer Produkte immer anspruchsvoller. Genauer gesagt ist es nicht mehr mĂśglich, die Systeme klassisch zu konstruieren (vgl. auch Konstruktion). Diese klassische Herangehensweise ist heute das Systems Engineering (SE).
Gleichzeitig steigt die Anzahl der Anforderungen â beispielsweise technische, kundenbezogene, umweltrechtliche und sicherheitsrelevante â sodass Systeme in einer Umgebung von Tausenden Anforderungen entstehen. SE ist eine moderne Methodik, um diese Komplexität zu erfassen. Dabei ist SE grundsätzlich ein Mittel zum Zweck und kein selbstständiges Ziel.
Dabei kann SE helfen, das Verhalten, die Effekte oder Auswirkungen eines Systems besser zu untersuchen. Dies ist besonders wichtig, wenn das System zu Beginn der Entwicklung noch viele Unbekannte aufweist und am Ende typischerweise im Rahmen des Testings und der Qualitätssicherung (QS) (vgl. auch Total Quality Management) Defekte gefunden und beseitigt werden mßssen. Die Kosten fßr diese späten Probleme sind zehnmal hÜher als die Kosten fßr eine Investition in das Systemdesign mittels SE. Ein besonderes Augenmerk liegt dabei auf der Durchgängigkeit und Nachvollziehbarkeit der Anforderungen. Das SE ist jedoch nicht fßr das Management der Anforderungen zuständig, sondern erarbeitet, verbessert und prßft die Spezifikationen der einzelnen Systemelemente zusammen mit der Systemarchitektur und anderen Teilbereichen. Ein hoher Qualitätsstandard innerhalb des SE wird auch durch solides Projektmanagement und die Unterstßtzung des Topmanagements (und auch Mittelmanagement) gewährleistet.
Angrenzende Fachgebiete
Es ist offensichtlich, dass viele spezielle Bereiche innerhalb des Produktentstehungsprozess mit den Teilbereichen des Systems Engineering in BerĂźhrung kommen. Die steigende Anzahl von komplexen und sehr unterschiedlichen Systemen erwirkt immer grĂśĂere Ăberschneidung zwischen diesen Bereichen. Viele Teilbereiche begreifen ihre eigenen Leistungen nur als Teil der grĂśĂeren Gebiete, sie tragen jedoch auch zur Weiterentwicklung und Forschung des Systems Engineering bei.
Im Folgenden werden einige Disziplinen beschrieben. Weitere Fachgebiete sind Dokumentenmanagement, Konfigurationsmanagement, Produktentwicklung, Prozessmanagement, Qualitätsmanagement bzw. Qualitätssicherung, Releasemanagement, Variantenmanagement uvm.
Softwareentwicklung
Die Softwaretechnik ist seit jeher entscheidend fĂźr die Fortentwicklung von Technologie im Sinne der Computer- bzw. digitalen Revolution. In diesem Zusammenhang sind die Technologien Computer Aided Engineering (CAE) und Computer Aided Design (CAD) zu nennen. Auch das Systems Engineering (SE) konnte sich dank moderner Software weiterentwickeln. Einige Beispiele, die sich auf SE auswirken sind die Formale Methoden und Formale Sprachen.
Software im Sinne des SE hat genau dann eine Teilaufgabe, wenn das System teilweise oder vollständig auf Software beruht. In diesem Fall berßcksichtigt das SE dieses Subsystem. Dies kann eine oder mehrere Softwares in einem oder mehreren Bausteinen (Microcontrollern, System-on-a-Chip usw.) sein.
Grundlegend ist Softwareentwicklung nicht die Aufgabe des Systems Engineering (SE). Software wird von einem Software-Team entwickelt und von Softwaretestern sowie Qualitätsingenieuren ßberprßft. Sie ist eng verzahnt mit den o. g. Disziplinen, bezieht Arbeitsgegenstände aus diesen oder liefert Ergebnisse als Teil eines ßbergeordneten Prozesses bzw. des eigentlichen Softwareentwicklungsprozesses.
Sicherheitstechnik (Safety)
â
Hauptartikel
:
ISO 26262
,
IEC 61508
und
Sicherheit#Technische_Sicherheit,_Betriebssicherheit
Sicherheitstechnik bzw. englisch Safety Engineering wird heute Ăźberall dort angewandt, wo Menschen groĂe komplexe Ereignisse absichern wollen, damit diese Systeme keine Schäden auslĂśsen kĂśnnen. Die meisten dieser Sicherheitstechniken dienen dazu, geplant mit Fehlern umzugehen.
Relevante Sicherheitsstandards der Automobilindustrie sind z. B. ISO 26262 Funktionale Sicherheit und fĂźr autonome Fahrzeuge der ISO 21448 (SOTIF). Dabei wird häufig der âSafety-by-Designâ-Ansatz gewählt, bei dem bereits in der frĂźhen Phase der Entwicklung Sicherheitstechniken angewendet werden.
Verschiedene Entwicklungsstandards definieren Risikokategorien und Modelle fßr Sicherheitsebenen bzw. Sicherheitsanforderungsstufen und leiten daraus Anforderungen an die Entwicklung und Qualitätssicherung ab. Ein weiterer Bereich ist die Fehlerbaumanalyse (FTA), die auf das gesamte System oder Teilsysteme und deren Domänen wie Software anzuwenden ist.
Safety ist jedoch keine Aufgabe des Systems Engineerings (SE), sondern dedizierter Sicherheitsingenieure bzw. Fachexperten. FĂźr Safety ist Erfahrung erforderlich. Sie wird von eigenen Standards, Normen und anderen Rahmenbedingungen wie eigenen Safety-Tests begleitet. Im Rahmen der Aufgabe und Anforderungen an das System muss das SE jedoch mit dem Safety Engineering zusammenarbeiten.
Informationssicherheit (Security)
Die Informationssicherheit (englisch Security Engineering bzw. englisch Cybersecurity) seit Beginn des Informationszeitalter (vgl. auch Internet), insbesondere bei der Entwicklung sicherheitsrelevanter Systeme, immer wichtiger. Ziel dabei ist es potentielle Angriffsvektoren auf das System zu identifizieren, Sicherheitsziele und SchutzmaĂnahmen zu definieren. Dabei wird, wie im Falle des Safety Engineering ein âSafety-by-Designâ-Ansatz gewählt, womit schon in der frĂźhen Phase der Entwicklung der Informationssicherheit ein hoher Stellenwert zukommt.
Security ist jedoch keine Aufgabe des Systems Engineering (SE), sondern eine eigenständige Fachdisziplin. Im Rahmen seiner Aufgaben und Anforderungen muss das SE jedoch mit dem Security Engineering zusammenarbeiten.
Betriebssicherheit bzw. Reliability, Availability, Maintainability, Safety (RAMS)
â
Hauptartikel
:
RAMS
Betriebssicherheit (oder Ausfallsicherheitentwicklung bzw. englisch Reliability Engineering oder englisch Reliability, Availability, Maintainability, Safety (RAMS)) ist ein weiteres Teilgebiet, um sicherzustellen, dass ein System die Nutzererwartungen oder die Fehlerfreiheit während des Produktlebens erfßllt.
Reliability Engineering wird im Idealfall auf das ganze System mit seiner Hard- und Software und anderer Komponenten angewandt. Es ist Merkmalen des Qualitätsmanagements verknßpft, z. B. der der Wartbarkeit. Reliability Engineering wird oft mit Teilbereichen der Sicherheitstechnik angewandt, wie Ausfallverhalten und Fehlerbäume. Reliability Engineering baut auf mathematischer Statistik (vgl. auch Verteilungen), Wahrscheinlichkeitstheorie und Betriebssicherheitstheorie.
Betriebssicherheit ist jedoch keine Aufgabe des Systems Engineering (SE), sondern eine eigenständige Fachdisziplin. Im Rahmen seiner Aufgaben und Anforderungen muss das SE jedoch mit dem Reliability Engineering zusammenarbeiten.
Schnittstellendesign
â
Hauptartikel
:
Interfacedesign
Das Schnittstellendesign beschäftigt sich damit, die Teile eines Systems miteinander zu verbinden. So werden z. B. Kommunikationsprotokolle bestimmt, um die Interaktionen der Daten und Datenflßsse eines Systems bzw. Subsystems sicherzustellen.
Ein Beispiel hierfĂźr ist, dass Signale die ein System/Gerät verlassen innerhalb einer Toleranz liegen mĂźssen oder der Empfänger eine grĂśĂere Signaltoleranz haben muss als der Sender, um die Funktionen des Systems aufrechtzuerhalten. Zusätzlich muss definiert werden, wie groĂ im Fehlerfall z. B. die Spannung am Sender werden darf und wie groĂ die Toleranz des Empfängers sein muss, damit keine Fehlerfortpflanzung eintritt. Ein weiterer Aspekt ist die Mensch-Computer-Interaktion (englisch human-computer interaction (HCI)), die eintritt, wenn das System mit einem Benutzer kommuniziert, von einem Benutzer bedient wird oder andere Funktionen ausfĂźhren soll. Zu beachten ist auĂerdem, dass jedes System meist ein Subsystem eines anderen ist. Ein Pumpenhersteller sollte sich daher beispielsweise Gedanken darĂźber machen, wie seine Kunden die Pumpe einsetzen wollen, und die Schnittstellen dementsprechend gestalten, frei nach dem Motto âJedes System ist irgendjemandes Subsystemâ.
Die Entwicklung, das Design und die Spezifikation der Schnittstellen ist Teil des Systems Engineering bzw. eine Hauptaufgabe, da Ăźber die Schnittstellen die einzelnen Bausteine oder Elemente miteinander verbunden werden. Diese VerknĂźpfungen werden auf physikalischer, logischer, abstrakter, textueller oder visueller Ebene dargestellt. Die Verifikation der Schnittstellen ist ebenfalls Teil des SE.
Kognitives Systems Engineering
Kognitives Systems Engineering sieht den Menschen als Teil des Systems. Kognitives Systems Engineering hängt stark mit den Erfahrungen, die ßber Jahrzehnte in den Anwendungen der beiden Teilbereiche Kognitionspsychologie und dem SE gemacht wurden, zusammen.cite-ref-14[14]
Beim Kognitiven Systems Engineering liegt der Fokus auf der Erforschung der Interaktionen zwischen Mensch und Umwelt. Ziel ist es, Systeme zu entwickeln, die das menschliche Denken integrieren. Kognitives Systems Engineering befasst sich mit folgenden Punkten:
⢠Probleme die durch die Umwelt auftreten
⢠Notwendigkeit von Vermittlern (Mensch und Software)
⢠Interaktion der verschiedenen Systeme und Technologien, um die Situation beeinflussen zu kÜnnen.
Risikomanagement
Das Risikomanagement ist eine eigene Fachdisziplin, die in manchen Industrien eng mit dem Systems Engineering (SE) zusammenwirkt. Ein Beispiel hierfßr ist die Raumfahrtindustrie. Generell wird versucht, mÜgliche Gefahren von Entwicklungen abschätzbar zu machen, sei es zum Zweck der Systementwicklung selbst oder als Ergebnisse von SE-Entwicklungen fßr das Risikomanagement. Teilweise wird bereits in der Angebots- bzw. Akquise-Phase eine Anforderungen an das Risikomanagement gestellt (vgl. auch Risikobewertung) die sich auf das SE auswirkt.
Beispielsweise werden in der Raumfahrt zu Beginn eines Projekts bestimmte Reserven gefordert werden, die bei den Meilensteinen nicht unterschritten werden dßrfen. Zum Beispiel muss die Masse eines Satelliten beim sogenannten Preliminary Design Review (PDR) mindestens 10 % unter dem spezifizierten Wert liegen. Dieser Wert ist wiederum abhängig vom Status der verschiedenen Elemente (z. B. Wiederverwendung eines Solar Arrays 2 % der Masse des Solar Arrays, bei Neuentwicklung mit neuen Zelltypen mit besserem Wirkungsgrad 10 %).
Risikomanagement ist jedoch keine Hauptaufgabe des Systems Engineering (SE), sondern eine eigenständige Fachdisziplin. Im Rahmen seiner Aufgaben und Anforderungen muss das SE jedoch mit dem Risk Engineering oder Risikomanagement zusammenarbeiten.
Auslegungen und Variationen
Fßr eine durchgängige Beschreibung des zu entwickelnden Systems ist es wichtig, abgestimmte Prozesse, Methoden und Tools (PMT) fßr Analyse und Entwicklung auf System- und Implementierungsebene zu nutzen. Eine MÜglichkeit zur durchgängigen Beschreibung des Verhaltens und der Struktur des Systems besteht in der Nutzung von Konzepten des Model-Based Systems Engineering (MBSE). Es sind die folgenden Modelle und Methodiken bekannt:
SysML
â
Hauptartikel
:
Systems Modeling Language
Als beschreibende Modellierungssprache kann dabei die SysML dienen, welche in der Version 1 auf Grundlage der UML entwickelt wurde.cite-ref-15[15] Derzeit gibt es eine Reihe von kommerziellen und Open Source Tools die spezifische SysML Implementierungen auf Basis der SysML v1.x anbieten (z. B. Enterprise Architect von SparxSystems, IBM Rational Rhapsody, Eclipse Papyrus, CATIA Magiccite-ref-16[16] etc.). Idealerweise erlaubt die eingesetzte PMT LÜsung eine durchgängige und nachvollziehbare Systementwicklung vom Anforderungsmanagement ßber das System Modell bis hin zur Verifizierung und Validierung.
Mit SysML v2 wird derzeit eine neue Version der Modellierungssprache entwickeltcite-ref-17[17], die eine verbesserte semantische Klarheit auf Basis einer von der UML unabhängigen Kernel Modeling Language (KerML)cite-ref-18[18], maschinenlesbare Modellrepräsentationen und eine standardisierte API fßr die Interoperabilität mit anderen Engineering-Toolscite-ref-19[19] bietet. SysML wird in den folgenden und anderen Branchen verwendet:
⢠In der Automobilindustrie bzw. dem Automobilbau integrieren einige Hersteller ihre SysML-Werkzeuge mit anderen Werkzeugen ihrer Engineering-Infrastruktur.cite-ref-20[20]
⢠Einsätze des No Magic Cameo Systems Modeler und IBM Engineering Rhapsody finden sich im Verteidigungsbereich oder der Wehrtechnik, besonders beim Verteidigungsministerium der Vereinigten Staaten.cite-ref-21[21]
Data Driven Systems Engineering (DDSE)
Data Driven Systems Engineering (DDSE) Ansätze fokussieren sich neben der Beschreibung von Systemen, auch auf die Formelzusammenhänge von technischen Daten daraus automatisiert berechnete Eigenschaften von Systemen.cite-ref-22[22] Fßr die hierbei eingesetzten PMT steht dabei nicht ein einheitliches Datenmodell im Vordergrund, sondern automatisierte Berechnungen, Schnittstellen und die Integration von Werkzeugen. In der Umsetzung schaffen Engineering Information Management (EIM) Systeme damit im Engineering Alltag eine Verbindung und Rßckverfolgbarkeit zwischen Daten entlang des V-Modells. Somit kÜnnen beispielsweise zahlen-basierte Anforderungen direkt in Berechnungen und Simulationen ßbernommen werden und deren Ergebnisse automatisiert in Dokumenten aktualisiert werden.
DDSE ist nicht mit den Aktivitäten des Data Sciencezu verwechseln.cite-ref-23[23] Ăberlappungen der Themengebiete sind jedoch nicht auszuschlieĂen.
Arcadia
â
Hauptartikel
:
Arcadia (Ingenieurwesen)
Arcadia (englisch Architecture Analysis & Design Integrated Approach) ist eine modell-orientierte Methode des System Engineerings (SE), mit deren Hilfe bei der Planung komplexer Systeme die verschiedenen Teilbereiche (z. B. der Systemarchitektur) definiert und in MBSE-Modellen beschrieben werden. Sie wurde von SysML beeinflusst und stellt eine modellier-methodische Weiterentwicklung dar.cite-ref-24[24]
Mit ihrer Anwendung sollen die Anforderungen eines Auftraggebers detailliert verstanden werden. Alle Aspekte eines umzusetzenden Produktes sollen fĂźr alle beteiligten Ingenieur-Disziplinen (Mechanik, Hydraulik, Elektronik, Elektrik, Software) so beschrieben werden, dass sie einer LĂśsung zugefĂźhrt werden kĂśnnen.
Mit dem Open Source Werkzeug Capella, angeboten von der Eclipse Foundation, kÜnnen solche interdisziplinären MBSE-Modelle Arcadia-basiert erzeugt werden. Auch die Integration mit einem Produktlebenszyklus oder PLM-Software kann abgesichert werden.cite-ref-25[25] Arcadia wird in den folgenden und anderen Branchen und Zusammenhängen verwendet:cite-ref-26[26]
⢠Arcadia wird gemeinsam mit Capella in einer ganzen Reihe von Branchen eingesetzt. Fallbeispiele beschreiben Arcadia/Capella-Projekte bei Thales Australien, Deutsche Bahn â Digitale Schiene Deutschland, UK Atomic Energy Authority, Rolls Royce, Ariane Group, CNES, Autonomous Train Projekt, Framatome und Continental Automotive. Die European Space Agency (ESA) ist ebenfalls ein Arcadia/Capella Nutzer.
⢠Ein anderer Anwendungsbereich ist das MBSE-Explorations-GroĂprojekt mit Arcadia und Capella beim weltgrĂśĂten Hersteller fĂźr Mikroelektrionik-Herstellungsmaschinen ASML.cite-ref-29[29]
⢠Darßber hinaus werden Arcadia und Capella bei einer Vielzahl von industriellen Akteuren eingesetzt.cite-ref-30[30] Ein Spezialfall ist dabei die Siemens AG, die gemeinsam mit OBEOcite-ref-31[31] Arcadia und Capella in das Produktportfolio von Siemens Digital Industries Software integriert hat.cite-ref-32[32]cite-ref-33[33]
Studium und Weiterbildung
In Deutschland gibt es Hochschulen und Universitäten, die Systems Engineering als Präsenz- oder Fernstudiengang anbieten. Ein Beispiel ist die Universität der Bundeswehr MĂźnchen. Die Studierenden lernen dabei verschiedene Ansätze, Methoden und Prozesse des Software Engineering (SE) kennen. Ihnen wird das nĂśtige âRĂźstzeugâ vermittelt, um komplexe Systeme mit unterschiedlichsten Anforderungen Ăźber den gesamten Systemlebenszyklus hinweg zu strukturieren, zu analysieren, zu spezifizieren, zu entwickeln und anzupassen. Weitere Studiengänge werden von der TH Ulm angeboten, z. B. der Master-Studiengang âSystems Engineering and Managementâ.cite-ref-36[36] Die Hochschule Landshut bietet seit 2009 einen zusätzlich von der Gesellschaft fĂźr Systems Engineering (GfSE) akkreditierten Masterstudiengang âSystems Engineeringâ an.cite-ref-37[37] Die Hochschulen Augsburg, Kempten und Neu-Ulm bieten den Studiengang Systems Engineering an. In der Schweiz wird SE vorwiegend an der ETH ZĂźrich als im Rahmen der Abteilung Engineering und Systeme (E&S) angeboten.cite-ref-38[38]
Die genauen Details zum Studium sind bei den jeweiligen Hochschulen zu erfragen.
Zertifizierung
Seit dem Jahr 2012 bietet die Gesellschaft fĂźr Systems Engineering (GfSE) in Kooperation mit dem TĂV Rheinland als akkreditierte Zertifizierungsstelle eine berufsbegleitende Personalzertifizierung fĂźr Systems Engineers als âCertified Systems Engineer (GfSE)â an. Die Zertifizierung bietet die drei Zertifizierungsstufen C (âVerstehenâ), B (âAnwendenâ) und A (âBeherrschenâ), wobei A den Experten-Level darstellt.
| SE-Zert (GfSE) | INCOSE-Entsprechung |
|---|---|
| Level C â verstehen | ASEP |
| Level B â anwenden | CSEP |
| Level A â beherrschen | ESEP |
Die Stufe C dauert fßnf Monate, beinhaltet etwa zwÜlf Präsenztage bei einem lizenzierten Schulungsanbieter und endet mit einer zweistßndigen Prßfung durch die SE-TREC GmbH und GfSE-Assessoren. Das verliehene Zertifikat stellt einen unabhängigen Nachweis von Kenntnissen im Systems Engineering dar. Inhaber der SE-Zertifikate Level C und B kÜnnen auf Antrag das entsprechende INCOSE-Zertifikat beantragen.cite-ref-39[39]
Organisationen
⢠The International Council on Systems Engineering (INCOSE)
⢠Gesellschaft fßr Systems Engineering (German Chapter of INCOSE)
⢠Swiss Society of Systems Engineering (Swiss Chapter of INCOSE)
⢠Systems Engineering und Evaluation Centre (SEEC)
Siehe auch
Literatur
⢠W. F. Daenzer, F. Huber: Systems Engineering. Methodik und Praxis. 11. Auflage. Verlag Industrielle Organisation, Zßrich 1999, ISBN 3-85743-998-X.
⢠Rainer Zßst: Einstieg ins Systems Engineering, kurz und bßndig. 3. Auflage. 2004, ISBN 3-85743-721-9.
⢠Reinhard Haberfellner, Olivier L. de Weck, Ernst Fricke, Siegfried VÜssner: Systems Engineering. 12. Auflage. Orell Fßssli, Zßrich 2012, ISBN 978-3-280-04068-3.
⢠Tim Weilkiens: Systems Engineering with SysML/UML: Modeling, Analysis, Design. Morgan Kaufmann OMG Press/Elsevier, Amsterdam Boston 2007, ISBN 978-0-12-374274-2 (englisch, archive.org).
⢠Oliver Alt: Modellbasierte Systementwicklung mit SysML. Carl Hanser Verlag GmbH & Co. KG, Mßnchen 2012, ISBN 978-3-446-43066-2, doi:10.3139/9783446431270.
⢠Collective: NASA Systems Engineering Handbook. NASA SP-2016-6105 Rev2 Auflage. NASA, Washington, D.C. 2016 (nasa.gov [PDF]).
Weblinks
Fachspezifische Wikis:
⢠Advanced Systems Engineering Glossar (ASE-Glossar) von acatech, KIT und Fraunhofer IEM, IPK und IAO
⢠Guide to the Systems Engineering Body of Knowledge (SEBoK) von INCOSE, IEEE und Stevens Institute
WeiterfĂźhrende Weblinks:
⢠OMG Systems Modelling Language
⢠Systems Engineering Fundamentals. Defense Acquisition University Press, 2001 (PDF-Datei; 1,3 MB)
⢠Robert Shishko et al.: NASA Systems Engineering Handbook. (PDF; 2,6 MB) NASA Center for AeroSpace Information, 1995
⢠Systems Engineering Alphabet SEMP Consulting GmbH vertreten durch Dorfner und SchrÜter, 2024/2025 (kontinuierliche Erweiterung)
Einzelnachweise
cite-note-11. â Christof Ebert: Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing. Wiley, Hoboken, NJ 2012, ISBN 978-0-470-63619-0. Fehler in Vorlage:Literatur â *** Parameterproblem: Dateiformat/GrĂśĂe/Abruf nur bei externem Link
cite-note-33. â Systems Engineering and Standards | Homeland Security. United States Government, abgerufen am 23. Dezember 2022 (englisch).
cite-note-55. â Thiago J. InocĂŞncio et al.: Emergent Behavior in System-of-Systems: A Systematic Mapping Study. In: Proceedings of the XXXIII Brazilian Symposium on Software Engineering (= SBES '19). Association for Computing Machinery, New York, NY, USA 2019, ISBN 978-1-4503-7651-8, S. 140â149, doi:10.1145/3350768.3350779 (englisch).
cite-note-66. â Hannes Hick, Klaus KĂźpper, Helfried Sorger (Hrsg.): Systems Engineering for Automotive Powertrain Development (= Powertrain). Springer International Publishing, Cham 2021, ISBN 978-3-319-99628-8, doi:10.1007/978-3-319-99629-5 (englisch, springer.com [abgerufen am 17. November 2025]).
cite-note-77. â SE Standards. INCOSE, abgerufen am 17. November 2025 (englisch).
cite-note-99. â History of Systems Engineering. In: INCOSE. Abgerufen am 17. November 2025.
cite-note-1010. â Garrett Shea: Systems Engineering Handbook. 6. Februar 2019, abgerufen am 6. April 2022.
cite-note-1111. â Andreas Poller: Exploring and managing the complexity of large infrastructure projects with network theory and modelâbased systems engineeringâThe example of radioactive waste disposal. In: Systems Engineering. Band 23, Nr. 4, Juli 2020, ISSN 1098-1241, S. 443â459, doi:10.1002/sys.21537 (englisch, wiley.com [abgerufen am 7. Februar 2022]).
cite-note-1212. â Samira Keivanpour: Circular Economy at Micro LevelâA System Engineering Perspective. In: Circular Economy in Engineering Design and Production. Springer International Publishing, Cham 2024, ISBN 978-3-03144651-1, S. 1â21, doi:10.1007/978-3-031-44652-8_1 (englisch, springer.com [abgerufen am 7. November 2024]).
cite-note-1515. â Systems Modeling Language (Wikipedia): Website Mai 2006.
cite-note-1616. â CATIA Magic. 22. Mai 2023, abgerufen am 23. Februar 2025.
cite-note-1717. â About the OMG System Modeling Language Specification Version 2.0 beta. Abgerufen am 23. Februar 2025.
cite-note-1818. â About the Kernel Modeling Language Specification Version 1.0 beta 2. Abgerufen am 23. Februar 2025.
cite-note-1919. â About the Systems Modeling API and Services Specification Version 1.0 beta 2. Abgerufen am 23. Februar 2025.
cite-note-2020. â sodiuswillert.com
cite-note-2121. â sodiuswillert.com
cite-note-2222. â Denis Tissen, Ingrid Wiederkehr, Christian Koldewey, Roman Dumitrescu: Exploring data-driven model-based systems engineering: a systematic literature review. IEEE, 2023, ISBN 979-83-5031335-2, S. 1â6, doi:10.1109/ICTMOD59086.2023.10438129 (ieee.org [abgerufen am 17. November 2025]).
cite-note-2424. â Is Capella a SysML Tool ? Eclipse Foundation, abgerufen am 18. November 2025 (englisch).
cite-note-2525. â Teamcenter System Modeling Workbench im Siemens Produktportfolio. Abgerufen am 20. Dezember 2022.
cite-note-2626. â Capella MBSE Tool - Case Studies. Eclipse Foundation, abgerufen am 18. November 2025 (englisch).
cite-note-2727. â Sicherungstechnik bei Eisenbahnen in Nordeuropa. Abgerufen am 20. Dezember 2022.
cite-note-2828. â Projektarbeit fĂźr SmartRail 4.0 der europäischen Bahngesellschaften. (PDF) Abgerufen am 20. Dezember 2022.
cite-note-2929. â MBSE-Explorationsprojekt bei ASML. Abgerufen am 20. Dezember 2022.
cite-note-3030. â Weitere industrielle Capella Nutzer. Abgerufen am 20. Dezember 2022.
cite-note-3131. â Capella Erweiterungen und Ergänzungen. Abgerufen am 20. Dezember 2022.
cite-note-3232. â Teamcenter System Modeling Workbench. Abgerufen am 20. Dezember 2022.
cite-note-3333. â Teamcenter System Modeling Workbench im Siemens Produktportfolio. Abgerufen am 20. Dezember 2022.
cite-note-3434. â Capella Days. Abgerufen am 20. Dezember 2022.
cite-note-3535. â Capella Webinare. Abgerufen am 20. Dezember 2022.
cite-note-3636. â Technische Hochschule Ulm. THU, abgerufen am 17. November 2025 (deutsch).
cite-note-3737. â Systems Engineering Master - Hochschule Landshut. Hochschule Landshut, abgerufen am 17. November 2025.
cite-note-3838. â Engineering und Systeme. ETH, abgerufen am 17. November 2025.
cite-note-3939. â GfSE: SE-Zert. Abgerufen am 25. Januar 2018.